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Abstract 


Entities responsible for distributing work across a group of systems 
traditionally do not know a great deal about the ability of the 
applications on those systems to complete the work in a satisfactory 
fashion. Workload management systems traditionally know a great deal 
about the health of applications, but have little control over the 
rate in which these applications receive work. The 
Server/Application State Protocol (SASP) provides a mechanism for 
load balancers and workload management systems to communicate better 
ways of distributing the existing workload to the group members. 
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1. Introduction 


1.1. Overview 


SASPvl September 2006 


The Server/Application State Protocol is designed to enable load 


(1) 
(2) 


balancers or schedulers 
from Workload Managers, 


members of load balancing/scheduling groups, 


to receive traffic weight recommendations 
to register with Workload Managers 


and (3) to enable 


Workload Managers to suggest new load balancing group members to load 


balancers and schedulers 


The figure below shows where the SASP entities are in typical load 


balancing topology. 


| Request | <------ >| Load 
| Origins | <------ >|Balancer | 
> | 
| 
SASP | 


| Group 


Group | 


Figure 1 


SASP is a binary protocol that facilitates communication from load 


The connection between 


balancers/schedulers to Workload Managers. 
the Group Workload Manager (GWM) 
expected to be a long-running TCP connection. 


and the load balancer/scheduler is 


In SASP interactions, 


the GWM acts as a SASP server waiting to receive connections from the 


other SASP components. 


Server port 3860 has been registered with the 


IANA for SASP communications. 


It is expected that all SASP 


components are configured with the DNS name of the GWM to develop 
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this connection. Security in SASP is handled by transporting binary 
messages over Secure Socket Layer/Transport Layer Security (SSL/TLS). 
This document only describes the message format and protocol behavior 
above the connection and security layers. Connection and security 
aspects including SSL's authentication and encryption will be 
implementation specific. 


1.2. Identities 


SASP identifies a load balancer by a UTF-8 string called a "LB UID". 
A group of "equivalent" servers providing a service is identified by 
a UTF-8 string called a "Group Name", which is interpreted in the 
context of the LB UID. A server is identified by its IP address and 
(optional) port and protocol numbers. A GWM is only identified 
implicitly as the entity on the other end of the TCP connection from 
a load balancer or group member. All of these identifiers are local; 
there are no globally unique identifiers. The LB UID and GroupName 
fields are unstructured so that components could assign values to 
these fields that are meaningful to an administrator. For example, 
in many cases, a load balancer would use the name an administrator 
provided for the serverfarm group as the groupname in a SASP- 
specified group. Since the naming options in industry load balancers 
do not carry explicit naming restrictions, SASP naming options also 
carry no naming restrictions. 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Conventions Used in This Document 


o Load Balancer - Entity responsible for distributing requests 
amongst the available members. 


o Member - Machine, process, or application used to service 
requests. 


o Group Workload Manager (GWM) - Entity responsible for reporting or 
managing a group of members on multiple machines. 


4. General Message Structure 
Any string interpreted by the group workload manager is assumed to 
use UTF8. Components implementing SASP MUST support the printable 


ASCII subrepertoire of UTF8 (0x20-0x7E). Components MAY also choose 
to provide support for additional UTF8 character encodings. It is 
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recommended that customers using SASP-enabled products configure the 
string-generating components (load balancers and group members) to 
use the same character repertoire. 


Many of the SASP structures involve the transfer of multi-byte 
integer values. In all cases where multi-byte integer values are 
used, they are considered to be in network-byte order (big-endian). 


SASP is organized into several message components. For extendibility 
and ease of processing, each message component is described in a TLV 
(Type, Length, Value) format. An illustration of the SASP structure 
can be found in the example below. The first section is the header 
followed by the message component type. As mentioned, the header, 
message component, and all other components have a TLV format. Each 
component value contains a variable number of fields, some of which 
refer to upcoming components (explained component descriptions are in 
upcoming sections). After the first message component, any number of 
additional components may be included (as stipulated in the fields of 
the message type). 


El Type (SASP Header Type) | 


| SASP | ---------------------------------- 

| Header |L| Length of SASP header TLV | 

O a | 

| |v| Header fields | 

EE EE | 
T| Type (Message Type) 

Message, HERSTEL ER 
| Type A Length of this Message Type TLV | 
| Component |---------------------------------- | 
| 
| 


T| Type (Component Type) | 


|Component-1 |L| Length of this TLV | 


|T| Type (Component Type) | 


Bivens Informational [Page 5] 


RFC 4678 SASPvl September 2006 


Figure 2 
4.1. TLV Structure 
An illustration of the TLV format is shown below. The Type is a 
two-byte field containing a binary value for the component type. The 
Length is a two-byte field containing the size of the TLV in bytes 
(including the Type and Length fields). The Value field is a 
variable-length field that actually contains the data of the 
component. 
< XXXX XXXX XXXX XXXX, XXXX XXXX XXXX XXXX, XXXX........... XXXX > 
Type (2 bytes) Length (2 bytes) Value (variable) 
Figure 3 
4.2. Component Types 


The TLV structure requires a type value for each protocol component. 
All SASP types are listed in this section. 


Reserved 0x0000-0x1000 

Message Types 
Registration Request 0x1010 
Registration Reply 0x1015 
DeRegistration Request 0x1020 
DeRegistration Reply 0x1025 
Get Weights Request 0x1030 
Get Weights Reply 0x1035 
Send Weights 0x1040 
Set Load Balancer State Request 0x1050 
Set Load Balancer State Reply 0x1055 
Set Member State Request 0x1060 


Set Member State Reply 0x1065 
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Utility Component Types 
SASP Header 0x2010 
Singular Component Types 
Member Data 0x3010 
Group Data 0x3011 
Weight Entry Data 0x3012 
Member State Instance 0x3013 
Group Component Types 
Group of Member Data 0x4010 
Group of Weight Entry Data 0x4011 
Group of Member State Data 0x4012 
Reserved 0xF000-0xFFFF 
4.3. SASP Protocol Header 
An illustration of the SASP Header is found in the table below. It 
is expected that every message will start with the SASP Protocol 
Header component. 
0 il 2 3 


0123496789 0 1234506789 0 123456 YT BY 0.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| SASP header type (0x2010) | Size of this TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ + 
| Version | Message Length 


PR A + dd + dd SKEER + EE + $ 4 +++ +++ +++ +++ +++ 
| Message ID 

HR A + dd + dd — + dd + $ 4 + $ 4 +++ +++ +++ +++ +++ 

t-+-+-4+-+-4+-4+-4-4+ 


Figure 4 


o Version: The version of the protocol used in this message. 
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o Message Length: A 4-byte signed integer value representing the 
total length of the SASP message. It is said to be a signed 
4-byte value to make any Java implementations easier (or any other 
implementations without unsigned values); however, no negative 
lengths are valid. 


o Message ID: Each request message is given a 4-byte Message ID by 
the message originator, which is simply returned in the Message ID 
field of the reply. This field is meant to assist the requester 
in correlating replies to the appropriate request when many 


requests have been sent. In the Send Weights message (the only 
message transaction that has no reply), this field serves no 
purpose. 

4.4. Version Negotiation 


To negotiate the version of the protocol used by the entities 
involved in the connection, the GWM views the version included in the 
load balancer request as the load balancer's proposed version. 


If the GWM supports the version proposed by the load balancer, it 
will respond to the connection with the appropriate response code and 
the load balancer's proposed version in the response header. This 
proposed version should be the version used for all messages in this 
connection. 


If the GWM does not support the version proposed by the load 
balancer, the GWM will respond with a "message not understood" 
response code and the GWM's highest supported SASP version in the 
version field of the response header. This is an indication for the 
load balancer to come down to GWM's SASP version level. 
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5. Singular Protocol Components 


The most basic of SASP components are singular components because 
they describe a single instance of a member, member resource, member 
weight, or group. Some of the SASP components reuse other SASP 
components. When this is the case, any component being reused by a 
base component will simply be given immediately following the base 
component. Some examples of this technique are seen and explained in 
the Weight Entry and Member State Instance components. 


5.1. Member Data Component 


The member data component describes a particular member and is 
referred to by other components. 


0 1 2 3 
0 12 38 4 5 61:8 9 0.12 8 4 5°67 8 9 OL 234 B 67 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Member Data Type (0x3010) | Size of this TLV 
EE EE EE EE GE EE EE EE EE EE o 
Protocol | Port 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


IP Address of Member 


+-+-+-+-+-+-+-+- 
| Label Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ +4 ++ +++ 


— + — + — + — + — + —+— 
— ++ + — + —+—+— 


Label 


dd + + + hd + dd + q — + + q ++ q +4 +++ +++ +++ +4++ 
Figure 5 


o Protocol: The assigned number of the IP transport layer used in 
the Protocol Field of the IP header. These are defined in 
[RFC1700]; however, a current list is maintained at 
http: //www.iana.org. 
for example: TCP = 0x06, UDP = 0x11, etc. 
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Port: The port number used for communication to the member. 

*** A value of 0 can be given for the Protocol and Port to signify 
a system level member. However, 0 shouldn't be perceived as a 
wildcard for either Port or Protocol fields (i.e., a 
deregistration request that includes a MemberData component with a 
0 for the port doesn’t mean deregister all applications listening 
on any port of that IP and protocol). 


IP Address: The current format is described by the following 16 
bytes, where IPv4 addresses are represented as "IPv4-compatible 


IPv6 addresses" [RFC4291]. In the following example, the x’s and 
zeros represent 4-bit hex values. The x’s describe arbitrary hex 
values. 


IPv4 Address: 00 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx 
IPv6 Address: XX XX XX XX XX XX XX XX XX XX XX XX XX XK XX XX 
Label length: The length, in bytes, of the label string to follow. 


Label: A UTF8 string that may be set while registering a member. 
This string is opaque to the GWM and is simply included with any 
correspondence containing the member data component. Note that 
the size of this label is <= 255 bytes. Because UTF8 character 
encodings may be up to 6 bytes, Care must be exercised by the load 
balancer or member to make sure the UTF8 string it sends the GWM 
is in fact <= 255 bytes. 
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5.2. Group Data Component 


The group data component simply describes a group with which to 
associate other singular components. 


0 1 2 3 
0123456789012 3 45.6 78 DO 12-3 AB 6 7:8 901 
TEE EE N EE EE EE GE EE 4>4>4>44+>4+>4>4—4>4>4>4+—>4—4+—4+—+ 

| Group Data Type (0x3011) | Size of this TLV 

ETE EE N EE NN NS OE H 
| LB UID Length | | 
+-+-+-+-+-+-+-+-+ + 


LB UID 


+ +-+-+-+-+-+-+-+-+ 
| Group Name Len 
EE tr q ee q q tanta + + q + + q + ++ ++ 


Group Name 
pj A AE 
Figure 6 
o LB UID Length: Length of the LB UID to follow (in bytes). 


o LB UID: A UTF8 string used as a unique identifier and a context 
for the Group Name (e.g., a UTF8 representation of the MAC address 
of the load balancer or some type of Universally Unique Identifier 
(UUID)). This string is used by the Group Workload Manager to 
associate application registration and deregistration, and to set 
state messages with the correct load balancer. This unique 
identifier should not be any longer than 64 bytes. 


o Group Name Len: Length of the Group Name field to follow (in 
bytes). 


o Group Name: A UTF8 string the load balancer has chosen to tell the 
Group Workload Manager that members being registered with this 
Group Name are equivalent in function. In Get Weight and 
DeRegistration messages, the Group Name may be omitted (Group Name 
Length = 0) to indicate all groups from the associated load 
balancer. 
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5.3. Weight Entry Data Component 


The Weight Entry Component is used by the get and send weight 
messages to associate a weight with a particular member (or Member 
Data). It also uses an opaque member state field and a general 
member flags field to denote extra information about a member 
(described below). When the Weight Entry component is used, the 
Member Data TLV it refers to is listed first, immediately followed by 
the Weight Entry TLV. 


0 1 2 3 
012 345067890 1203: 40506078 BO 1.2 BAD. BT 8 90 I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ++ + ++ ++ ++ += +++ 
| Member Data Type (0x3010) | Size of this Member Data TLV | 
dh + A A q + hd + + + q + + + + + +++ ++ ++ + +++ ++ 


Member Data Fields 


TT A EE 


| Weight Entry Type (0x3012) | Size of this Weight Entry TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| State Field | Flags Field | Weight 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 7 


o State Field: This field is used by the member to communicate state 
information to the scheduler. The information placed in this 
field is opaque to the GWM and will simply be forwarded to the 
scheduler with the member weights. There are no defined values 
for this field. 


o Flags Field: This field has several flag values that describe 
several attributes of the member. 


A. Contact Success Flag (set by the GWM): describes whether the 
member is currently running. If the contact success flag is 
off, this member should be avoided by the load balancer. 


+ XXXX XXXl The GWM has located this running system or 
application. 


+ XXXX xxx0 The GWM has not located this running system or 
application. 


B. Quiesce Flag (set by the load balancer or Member): used when 


an administrator would like to temporarily remove a member 
from the weight calculation, but not deregister it from the 
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group. When quiesced, the member will still show up in the 
weights, but the quiesce flag will be set, and its weight will 
be zero. When the administrator returns this member to 
active, the quiesce flag will be 0, and a weight will be 
provided. If the quiesce flag is on, this member should be 
avoided by the load balancer. 


+ xxxx xxlx The member is quiesced. 
+ xxxx xx0x The member is active (not quiesced). 


Registration Flag (set by the GWM): stores how the member was 
registered. 


+ xxxx x1lxx This member has been registered by the load 
balancer/scheduler. 


+ xxxx x0xx This member has registered itself. 


Confident Flag (set by the GWM): describes whether the GWM has 
knowledge of this member's state. If this flag is off for 
only some of the members in the group while the remaining 
members have valid weights, the load balancer should avoid 
sending work to those members with the confident flag off. If 
the confident flag is off for all valid group members, the 
load balancer should disregard any recommendation from the GWM 
until the confident flag comes back on for at least one 
member. In this case where all confident flags are off, the 
load balancer should determine the correct distribution of 
work by other means (perhaps a different advisor, previously 
configured static weights, etc.). 


The goal of the confident flag is to convey to the load 
balancer that it should look to other methods of distribution 
recommendations if the GWM cannot give recommendations for any 
of the valid group members. If some members of the group have 
the confident flag on but the contact flag off or the quiesced 
flag on (meaning these members should always be avoided) while 
the remaining members of the group have their confident flag 
off, the load balancer should determine the appropriate 
distribution of work for those members with the confident flag 
off by other means. 


+ xxxx lxxx GWM has determined it has knowledge of the state 
of this member. 


+ xxxx Oxxx GWM has no knowledge of the state of this member. 
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E. Leftmost four bits are reserved (0000 xxxx - 1111 xxxx). 


o Weight: This field represents the GWM's recommendation for the 
relative amount of work that should be sent to this member. This 
is a 16-bit field with a possible range of 0 to 65536. Load 
balancers should be prepared to receive a wide range of weight 
values. Load balancers with limited maximum weight values may 
restrict the granularity of management by the GWM and in turn 
cause less than optimal performance. Many existing 
implementations have supported a minimum raw weight range from 0 
to 100. 


5.4. Member State Instance Component 


The Member State Instance Component is used by the set member state 
message to indicate the sender's perceived state of the member 
mentioned. This component is used to set values that will ultimately 
end up in the WeightEntry component. When the Member State Instance 
component is used, the Member Data TLV it refers to is listed first, 
immediately followed by the Member State Instance TLV. 


0 1 2 3 
01234567890123456789012345678901 
AAA +++ +++ + + + ++ + + hh + + +++ + +++ ++ 
| Member Data Type (0x3010) | Size of this Member Data TLV | 
dh + Ph q hd tata tata ta + + ++ hh + ++ ++ +++ +++ 


Member Data Fields 


E 


| Member State Instance(0x3013) | Size of Member State Inst TLV 
dh + hh q + hd + + + + ++ ++ +++ ++ ++ ++ +++ 
| State Field | Flags Field | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 8 


o State Field: This field is used by the member to communicate state 
information to the load balancer or scheduler. There are no 
defined values for this field. 


o Flags Field: This field describes attributes of the member. 
Currently the only flag value defined is that of the quiesce flag. 
The quiesce flag is used when an administrator would like to 
temporarily remove a member from the weight calculation, but not 
deregister it from the group. When quiesced, the member will 
still show up in the weights, but the quiesce flag will be set, 
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and its weight will be zero. When the administrator returns this 
member to active, the quiesce flag will be 0, and a weight will be 
provided. 


A. Quiesce Flag 


+ xxxx xxxl The member or load balancer setting this state is 
quiescing this member. 


+ xxxx xxx0 The member or load balancer setting this state is 
placing the member in a non-quiesced state. 


B. Leftmost seven bits are reserved (0000 000x - 1111 111x). 
6. Group Protocol Components 


Group protocol components each contain a collection of related 


singular components. In particular, they associate Member Data, 
Weight Entry, or Member State Instance components to a particular 
Group Data component. In these cases, the particular "Group of x" 


component will be immediately followed by the Group Data component. 
The Group Data component will be immediately followed by any number 
of singular components the group contains. In figures listed in this 
document, a component type with an asterisk denotes a component that 
is repeated a number of times. 


6.1. Group of Member Data Component 


The "group of member data" component describes a particular group of 
members and is used in the registration message components. 


0 1 2 3 
01234567890123456789012345678901 
++ +++ + e + ta tata ta + — + + d+ + ++ +++ +++ +++ +++ 
| Group of Member Data (0x4010) | Size of GroupOfMemberData TLV | 
PR A A + e + dd $ + d+ + + d+ + ++ +++ +++ +++ +++ 
| Member Count | | 
EE ER +>+—+—+ + 
Group Data TLV 
PR A AO A +++ $ e e $ + d+ + + d+ + ++ +++ +++ +++ +++ 
*Array of Member Data Components 


EE 


Figure 9 
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o Member Count: The number of Member Data Components immediately 
following the Group Data structure. 


o Array of Member Data Components: There will be as many Member Data 
TLVs as Member Count has specified. A load balancer/scheduler 
would use these components to pass information that would enable 
the Group Workload Manager to identify the members to associate 
with this Group Name. The Member Data Component was described in 
Section 5.1. In DeRegistration messages, the Member Count may be 
set to O to indicate all members of a particular group. 


6.2. Group of Weight Data Component 


The "Group of Weight Data" Component is used by the get and send 
weight messages to create a list of Weight Entry Components for a 
particular group. 


0 1 2 3 

0 '1 2.38 4.5 6 1-8 9 0 d .2. 3 456, T 8 DO 1 2.3 4 56.78.9001 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Group Weight Entry Type (0x4011) | Size of GroupOfWeightEntry TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Weight Entry Count | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 


Group Data TLV 
EES E A OS E A E E E E DE N DS 
*Array of Weight Entry Data Components 
SEE A E E SE P E EG 
Figure 10 


o Weight Entry Count: The number of Member Data / Weight Entry 
combinations to follow the Group Data TLV. 


o Array of Weight Entry Data TLVs: There will be as many [Member 
Data / Weight Entry] TLVs as Weight Entry Count has specified. 
Each Weight Entry component is preceded by its corresponding 
Member Data component as explained in Section 5.3. This Member 
Data / Weight Entry data combination will repeat to form as many 
Weight Entry items as the Weight Entry Count specifies. 
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6.3. Group of Member State Data Components 


The "group of member state data" component describes a particular set 
of members and their corresponding state fields used in the Set 
Member State messages. 


0 1 2 3 

0: 1.23 4,5. 6078.9000 1.2 304,56 BA 00 102304 05:60 VR 9 OT 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Group Weight Entry Type (0x4011) | Size of GroupOfWeightEntry TLV| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Member State Instance Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 


Group Data TLV 
EA E E EE IE AE Oe ee E E sO EA E. 
*Array of Member State Data Components 
EE EE E EE EEU EEEE E cee dee E 
Figure 11 


o Member State Instance Count: The number of Member Data / Member 
State Instance combinations following the Group Data component. 


o Array of Member State Data Components: Each Member State Instance 
component is immediately preceded by its corresponding Member Data 
component as explained in Section 5.4. This Member Data / Member 
State Instance combination will repeat to form as many Member 
State items as the Member State Instance Count specifies. 


7. Protocol Messages 


SASP messages are a collection of TLVs (Type, Length, and Value 


components). The header has no information as to what type of 
message it is part of; the purpose-specific information is in the 
message component. This format could facilitate placing more than 


one message component in a single message; however, this use of 
multiple message components is not supported in every GWM and could 
produce indeterminate behavior. Similar to the other protocol 
components, when a message component needs to involve other 
components, the additional components immediately follow the message 
component. 
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All SASP requests sent to the GWM will be acknowledged with a reply. 
The reply contains information requested as well as a single-byte 
response code describing the success of the request. SASP defines 
some general response codes in the range of 0x00 - 0x3F that may be 
used regardless of the response message type. However, some request 
types may cause specific error conditions not covered by the general 


response codes. The response code range of 0x40 - 0xFF is used for 
these message-specific response codes. Any given SASP response will 
only contain one response code (depending on the error type). This 


section explains the format and purpose of specific SASP messages. 
7.1. Registration Request and Reply 


This exchange happens between the load balancer/scheduler and the 
Group Workload Manager as well as between the Group Workload Manager 
and the member to register the members in a group specified by Group 
Name. Applications are identified with an IP address, Protocol, and 
Port. Systems are identified only with an IP Address (Port = 0x0000 
and Protocol = 0x00). All members in a group have equivalent 
functionality, so the Group Workload Manager can direct routers, load 
balancers, and schedulers to any member in the group. Even though 
registrations can come from either the load balancer/scheduler or the 
actual member, member-initiated registrations will only be considered 
if the Trust flag is set while the state of the load 
balancer/scheduler is set. 


7.1.1. Registration Request 

0 1 2 3 

0.1. 2.34. 8 6 178 9 01.2.8 AD.6 1 8900102 3 45 61-8 DO 
dd + + dd hd +++ $ + q ++ ER +4 +++ +++ ++ ++ ++ 

SASP Header TLV 
dd + + dd + $ dd $ $ q — $ + q — dd q +4 + ++ +++ +++ +++ 
| Registration Req. Type (0x1010) | Size of Registration Req. TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flag Field | Group of Member Data Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
*Array of Group of Member Data Components 


ET O AO A A O O O A O O O A O O O AO O O A O o + 


*There will be as many Group of Member Data Components as "Group of 
Member Data Count" has specified. 


Figure 12 
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o Flag Field 
A. Load Balancer Flag 


+ xxxx xxxl The entity sending this message is the load 
balancer. 


+ xxxx xxx0 The entity sending this message is an 
Application. 


B. Leftmost seven bits are reserved (0000 000x - 1111 111x). 


o Group of Member Data Count: The number of "Group of Member Data" 
components immediately following the Registration Request 
component. 


o Array of Group of Member Data Components: Each "Group of Member 
Data" component is immediately followed by Group Data Components 
and its Member Data components (as described in Section 6.1). In 
the case where several of these "Group of Member Data" components 
may be present, the second "Group of Member Data" component only 
appears after all of the internal components that are referred to 
by the first "Group of Member Data" component are listed. The 
format is the same for all subsequent "Group of Member Data" 
components in the message. 


7.1.2. Registration Reply 
0 1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
SASP Header TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
[Registration Reply Type(0x1015)| Size of Registration Reply TLV| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Return Code | 
+-+-+-+-+-+-+-+-+ 
Figure 13 
o General SASP return codes (0x00 - 0x3F) 


* 0x00 Successful 


* 0x10 Message not understood 
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* 0x11 GWM will not accept this message from the sender. Reasons 
for this include the following: 
a. The message was not sent by a LB and trust flag is off 
b. LB attempted to address members of a different LB in the 
message 
c. Vendor specific criteria for this message type were not met. 


o Message-Specific return codes (0x40 - OxFF) 
* 0x40 Member already registered 
* 0x44 Duplicate Member in Request 
* 0x45 Invalid Group (determined by the GWM) 
* 0x50 Invalid Group Name Size (size == 0) 
* 0x51 Invalid LB UID Size (size == 0 or > max) 


* 0x61 Member is registering itself, but LB hasn’t yet contacted 
the GWM. This registration will not be processed. 


**The Invalid Group error return code refers to the LB or member 
attempting to form a group that the GWM considers invalid. For 
example, some GWM vendors may not support the registration of both 
System and Application members in the same group. To determine what 
can cause a GWM to return this error code, the vendor’s documentation 
must be consulted. 


7.2. DeRegistration Request and Reply 


This exchange happens between the load balancer/scheduler and the 
Group Workload Manager as well as between the Group Workload Manager 
and the Member to deregister members from a group specified by Group 
Name with the Group Workload Manager. Even though deregistrations 
can come from either the load balancer/scheduler or the actual 
member, member-initiated deregistrations will only be considered if 
the Trust flag is set with a Set LB State message. 
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7.2.1. DeRegistration Request 
0 1 2 3 
OI 2.3 4,5 6 1-8-9 0. 1:2. 8 4.056 T BOO. 1 2.3 4 5.6 7-8 9-01 
EE EE $ + q ++ q +4 +++ EE +++ 
SASP Header TLV 
Pod + + +++ +++ $ + q — $ + q d+ q +4 +++ +++ ER EE EF 
|DeRegistration Req. Type (0x1020) | Size of DeRegistration Reg. TLV| 
dd + + dd hd + dd $ q — $ + q dd q +4 +++ +++ +++ +++ 
| Flag Field | Reason | Group of Member Data Count | 
dd + + dd hd dd $ $ EE q +4 + ++ +++ +++ +++ 
*Array of Group of Member Data Components 


EA A A A A A A A A A A A A A A A A A A dd A dd o ++ 


*There will be as many Group of Member Data Components as "Group of 
Member Data Count" has specified. 


Figure 14 
o Flag Field 
A. Load Balancer Flag 


+ xxxx xxxl The entity sending this message is the load 
balancer. 


+ xxxx xxx0 The entity sending this message is an 
Application. 


B. Leftmost seven bits are reserved (0000 000x - 1111 111x). 


o Reason: Byte describing the reason for deregistering the group or 
instance. 


A. SASP-defined Reason Codes (0x00-0x7F) 
+ 0x00 No reason given. 


+ 0x01 Learned and Purposeful, i.e., a human has deconfigured 
this member from the load balancer configuration. 


+ 0x80-0xFF Open for vendor specific deregistration reason 
codes. 
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o Group of Member Data Count: The number of "Group of Member Data" 
components immediately following the DeRegistration Request 
component. 


o Array of Group of Member Data Components: Each "Group of Member 
Data" component is immediately followed by Group Data Components 
and its Member Data components (as described in Section 6.1). In 
this case, where several of these "Group of Member Data" 
components may be present, the second "Group of Member Data" 
component only appears after all of the internal components that 
are referred to by the first "Group of Member Data" component are 
listed. The format is the same for all subsequent "Group of 
Member Data" components in the message. 


** Tf Member Count equals zero in the Group of Member Data component, 
the Group Workload Manager will deregister the entire group. 


** Recall that the Group Data Component contains both a Unique LB 
Identifier field and a Group Name field. If the Group Data component 


has no Group Name (GroupData’s Group Name Length==0), the Group 
Workload Manager will deregister all groups associated with this load 
balancer. 


7.2.2. DeRegistration Reply 
0 1 2 3 
01.02 Del 56 7080900 A.D BA BG OT 8 9023 Ad GT BO 
ma EE EE O O A O A O A O A O A O O A O A O o + 
SASP Header TLV 

YH A AO A A O O O O A O A O A O A O O O A O O O A O A O A + H 
| DeReg. Reply Type (0x1025) | Size of DeReg. Reply TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Return Code | 

+-+-+-+-+-+-+-+-+ 

Figure 15 


o Return Code: A byte return code indicating the status of action 
taken. 


A. General SASP return codes (0x00 - 0x3F) 
+ 0x00 Successful 


+ 0x10 Message not understood 
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+ 0x11 GWM will not accept this message from the sender. 
Reasons for this include the following: 
a. The message was not sent by a LB and trust flag is off 
b. LB attempted to address members of a different LB in the 
message 
c. Vendor specific criteria for this message type were not 
met. 


B. Message-Specific return codes (0x40 - OxFF) 
+ 0x41 Application or System not registered 
+ 0x42 Unknown Group Name 
+ 0x43 Unknown LB UID 
+ 0x44 Duplicate Member in Request 


+ 0x46 Duplicate Group in Request (for remove all 
members/groups requests) 


+ 0x51 Invalid LB UID Size (size == 0 or > max) 


+ 0x61 Member is deregistering itself, but LB hasn't yet 
contacted the GWM. This deregistration will not be 
processed. 


7.3. Get Weights Request and Reply 


This exchange happens between the load balancer/scheduler and the 
Group Workload Manager to get weights for the groups specified in the 
list of GroupData objects. In the case of application load balancing 
(balancing workloads between applications with the same 
functionality), the load balancer would call the Group Workload 
Manager every Interval (parameter returned by the Group Workload 
Manager below) to get an array of weights and associated members 
(e.g., Applicationl 20, SecondCopyOfApplication 30, 


ThirdCopyOfApplication 5). The load balancer then uses these weights 
to determine the fashion in which work will be sent to each of the 
members. For example, in the case of weighted round robin, the load 


balancer/scheduler would then send a request to Applicationl, the 
next to SecondCopyOfApplication, and the next to 
ThirdCopyOfApplication. After 15 requests, the load 
balancer/scheduler would only send work to Applicationl and 
SecondCopyOfApplication. After an additional 30 requests, the load 
balancer/scheduler would only send requests to 
SecondCopyofApplication. After another 10 requests, the load 
balancer/scheduler product would start over using the weights of 20, 
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30, and 5 again; or if the Interval number of seconds have passed, 
the load balancer/scheduler would get a new set of weights. 


7.3.1. Get Weights Request 
0 1 2 3 
OF 1 2: 354050060 7: BP EO PAY MS OP “BR OF dB VALS. OPTS 8 190001 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
SASP Header TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Get Weights Reg. Type (0x1030) | Size of Get Weights Req. TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Group Data Count | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
*Array of Group Data Components 


AA A A A A A A A A A A A A A A A A A A A A A dd o o ++ 


*There will be as many Group Data Components as "Group Data Count" 
has specified. 


Figure 16 


o Group Data Count: The number of "Group Data" components 
immediately following the Get Weights Request TLV. 


o Array of Group Data Components: This array of Group Data 
Components lists the groups for which the load balancer wants to 
get weights. 


** If there is no group name in the Group Data structure of the Get 


Weights Request, the load balancer is requesting weights for all 
groups registered for the load balancer. 
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7.3.2. Get Weights Reply 

0 dL 2 3 

OL 2.8 4,56 7-8 90. 1.2.8 4056 N e890. 1 2.3 4 E 1-8 9 Od 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

SASP Header TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Get Weights Reply Type (0x1035) | Size of Get Weights Reply TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Return Code | Interval | Group of Weight 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Entry Data Count | | 
+-+-+-+-+-+-+-+-+ + 
*Group of Weight Entry Data Components 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


* There will be as many Group of Weight Entry Data Components as 
"Group of Weight Entry Data Count" has specified. 


Figure 17 


o Return Code: A byte return code indicating the status of action 
taken. 


A. General SASP return codes (0x00 - 0x3F) 
+ 0x00 Successful 
+ 0x10 Message not understood 
+ 0x11 GWM will not accept this message from the sender. 


Reasons for this include the following: 
a. LB attempted to address members of a different LB in the 


message 
b. Vendor specific criteria for this message type were not 
met. 
B. Message-Specific return codes (0x40 - OxFF) 


+ 0x42 Unknown Group Name 
+ 0x43 Unknown LB UID 


+ 0x46 Duplicate Group in Request 


Bivens Informational [Page 25] 


RFC 4678 SASPvl September 2006 


+ 0x51 Invalid LB uid Size (size == 0 or > max) 


o Interval: These two bytes indicate a recommended polling interval 
for the load balancer to use. The Group Workload Manager is 
stating that any polling interval smaller than the suggested 
interval would probably retrieve values before they have had a 
chance to change. 


o Group of Weight Entry Data Components: Each "Group of Weight Data" 
component is immediately followed by Group Data Components and its 
Weight Entry Data components (as described in Section 6.2). In 
this case, where several "Group of Weight Data" components may be 
present, the second "Group of Weight Data" component only appears 
after all of the internal components that are referred to by the 
first "Group of Weight Data" component are listed. The format is 
the same for all subsequent "Group of Weight Data" components in 
the message. 


7.4. Send Weights 


This exchange happens between the Group Workload Manager and the load 
balancer/scheduler to send the new weights for the group specified in 


Group Name. This message is unique in that it isthe only message 
exchange initiated by the Group Workload Manager and the only message 
that has no reply. In the case of application load balancing 


(balancing workloads between applications with the same 
functionality), the Group Workload Manager would message the load 
balancer at a possibly dynamic interval (chosen by the Group Workload 
Manager) to send an array of weights and associated members (e.g., 
Applicationl 20, SecondCopyOfApplication 30, ThirdCopyOfApplication 
5). The load balancer then uses these weights to determine the 
fashion in which work will be sent to each of the members. For 
example, in the case of weighted round robin, the load 
balancer/scheduler would then send a request to Applicationl, the 
next to SecondCopyOfApplication, and the next to 
ThirdCopyOfApplication. After 15 requests, the load 
balancer/scheduler would only send work to Applicationl and 
SecondCopyOfApplication. After another 30 requests, the load 
balancer/scheduler would only send requests to 
SecondCopyofApplication. After an additional 10 requests, the load 
balancer/scheduler product would start over using the weights of 20, 
30, and 5 again, if it has not yet received a new set of weights. 
The Group Workload Manager only sends this message if the Push flag 
has been enabled using a Set Load Balancer State message. 
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0 1 2 3 
0. d 2 34.5 61:89 0 di 2 34 -6°7 BY OO 12 AA 5678.9041 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


SASP Header TLV 


E e N o oo ooo +4 
| Send Weights Type (0x1040) | Size of Send Weights TLV | 
E hh ho ooo ++ 
| Group of Weight Data Count | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 


*Group of Weight Entry Data Components 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


* There will be as many Group of Weight Entry Data Components as 
"Group of Weight Data Count" has specified. 


Figure 18 


o Group of Weight Entry Data Components: Each "Group of Weight Data" 
component is immediately followed by Group Data Components and its 
Weight Entry Data components (as described in Section 6.2). In 
this case, where several "Group of Weight Data" components may be 
present, the second "Group of Weight Data" component only appears 
after all of the internal components that are referred to by the 
first "Group of Weight Data" component are listed. The format is 
the same for all subsequent "Group of Weight Data" components in 
the message. 


7.5. Set Member State Request and Reply 


This is a special exchange that can take place between the load 
balancer and the Group Workload Manager or between the Member and the 
Group Workload Manager to pass information about the state of the 
member including placing the member in quiesced or non-guiesced 
states. In particular, the load balancer/scheduler can use this 
message to quiesce a set of members. Members can also use this 
message to quiesce themselves as well as to pass certain state 
information to the load balancer/scheduler that is opaque to the 
Group Workload Manager. This opaque state information is passed to 
the load balancer/scheduler with the weights during get and send 
weight messages. 
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7.5.1. Set Member State Request 


0 1 2 3 
0. 1 2.3 4,5 6 7-8 9 01.2.8 4 B6 18 VO 1 2.3 4 BV 6 7.8901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


SASP Header TLV 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SetMemberState Req.Type (0x1060) |Size of SetMemberState Req. TLV| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flag Field | Group of MemberStateData Count | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 


*Array of Group of Member State Data Components 
+++ +++ +++ > +++ +++ +4 + ++ +++ +++ +++ 


*There will be as many Group of Member State Data Components as 
"Group of Member State Data Count" has specified. 


Figure 19 
o Flag Field 
A. Load Balancer Flag 


+ xxxx xxxl The entity sending this message is the load 
balancer. 


+ xxxx xxx0 The entity sending this message is an 
Application. 


B. Leftmost seven bits are reserved (0000 000x - 1111 111x). 


o Group of Member State Data Count: The number of "Group of Member 
State Data" components immediately following the Set Member State 
Request TLV. 


o Array of Group of Member Data Components: Each "Group of Member 
State Data" component is immediately followed by Group Data 
Components and its Member State Instance components (as described 
in Section 6.3). In the case where several "Group of Member State 
Data" components may be present, the second "Group of Member State 
Data" component only appears after all of the internal components 
that are referred to by the first "Group of Member State Data" 
component are listed. The format is the same for all subsequent 
"Group of Member State Data" components in the message. 
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Set Member State Reply 


ii 2 3 


0 1.2 34.5 67-8 9012 345 6 1.8 9:0 12345 67 8 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


SASP Header TLV 


+++ +++ +++ +++ +++ +>+>+>+>+>+>+>+>+>+>+—+—+ 
| Set Member State Reply (0x1025) |Size of SetMemberStateReply TLV| 
EE >>> +>+>+>+>+>+>+>+>+>+>+>+>+—+—+ 
Return Code | 
+>+>+>+>+>+>+>+—+ 


Figure 20 


Return Code: A byte return code indicating the status of action 


taken. 
A. General SASP return codes (0x00 - 0x3F) 
+ 0x00 Successful 
+ 0x10 Message not understood 
+ 0x11 GWM will not accept this message from the sender. 
Reasons for this include the following: 
a. The message was not sent by a LB and trust flag is off 
b. LB attempted to address members of a different LB in the 
message 
c. Vendor specific criteria for this message type were not 
met. 
B. Message-Specific return codes (0x40 - OxFF) 
+ 0x41 Application or System not registered 
+ 0x42 Unknown Group Name 
+ 0x43 Unknown LB UID 
+ 0x44 Duplicate Member in Request 
+ 0x46 Duplicate Group in Request 
+ 0x50 Invalid Group Name Size (size == 0) 
+ 0x51 Invalid LB UID Size (size == 0 or > than max) 
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+ 0x61 Member is setting state for itself, but LB hasn't yet 
contacted the GWM. This request will not be processed. 
7.6. Set Load Balancer State Request and Reply 
This is an exchange that can take place between the load balancer and 
the Group Workload Manager to pass information about the state (and 
partial configuration) of the load balancer. 
7.6.1. Set LB State Request 
0 1 2 3 
0.1 2:84 5 6,7 8.90 122.3. 43.6 N BY BT 2 3-45 6-7 8 9 0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
SASP Header TLV 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Set LB State Req. Type (0x1050) | Size of Set LB State Req. TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LB UID Length | | 
+-+-+-+-+-+-+-+-+ + 
LB UID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
LB Health LB Flags | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 21 


o LB UID Length: one-byte length field describing the size of the 
following LB UID. 


o LB UID: This should be the same unique identifier given when 
registering group members for this particular load balancer. 


o LB Health: This field gives the load balancer a chance to pass in 
a metric describing its own health or state. 


0x00 - 0x7F Least Healthy - Most Healthy 
0x80 - OxFF Reserved 
o LB Flags: 


A. Push Flag 
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+ xxxx xxx1 The load balancer should receive weights through 
the Send Weights message (GWM pushes weights to load 
balancer). Even if this flag is set, the GWM must still 
respond accordingly to any Get Weights messages from the 
load balancer. 


+ xxxx xxx0 The load balancer will send a Get Weights message 
to get the new weights. This is the default behavior. 
(load balancer pulls weights from GWM). 


B. Trust Flag 


+ xxxx xxlx Trust any member-initiated registration, 
deregistration, or set state message. Immediately reflect 
the registration, deregistration, or new state in the 
weights sent. 


+ xxxx xx0x Do not trust any member-initiated registration, 
deregistration, or set state message. Registration, 
Deregistration, and State Setting of members can only occur 
from the load balancer. Discard any member-initiated 
registration, deregistration, or set state message. This 
is the default behavior. 


C. No Change / No Send Flag 
+ xxxx xlxx The GWM must not include members whose weights 
and state (i.e., contact and quiesce flags) have not 
changed since they were last sent. 
+ xxxx x0xx The GWM must include the weights of all group 
members when sending the weights to this load balancer 
(including members whose weights and state have not 


changed). This is the default behavior. 


D. Leftmost five bits are reserved (0000 Oxxx - 1111 1xxx). 
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7.6.2. Set LB State Reply 


0 1 2 3 
0 1.2 34,5 67-8 9012 345 67.8 9012345 67 8 9 OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


SASP Header TLV 
EE EE +++ 
| Set LB State Reply (0x1025) | Size of Set LB State Reply TLV| 
+-+-+-+-+-+-+-+-+-+-+- +++ 
| Return Code | 
+-4+-+-+-4+-+-+-+4-+ 


Figure 22 


o Return Code: A byte return code indicating the status of action 
taken. 


A. General SASP return codes (0x00 - 0x3F) 
+ 0x00 Successful 
+ 0x10 Message not understood 
+ 0x11 GWM will not accept this message from the sender. 
Reasons for this include the following: 


a. LB attempted to address the state of a different LB 
b. Vendor specific criteria for this message type were not 


met. 
B. Message-Specific return codes (0x40 - OxFF) 
+ 0x51 Invalid LB UID Size (size == 0 or > max) 


8. Example of SASP Message Encoding 


This section provides an example of the actual SASP message encoding. 
For this example, we will look at a sample GetWeights Reply in which 
two webservers are registered to a serverfarm called FARM1. The IP 
addresses of the two webservers are 10.10.10.1 and 10.10.10.2. 
Currently the GWM has a weight of 40 for 10.10.10.1 and 20 for 
10.10.10.2. The load balancer has a unique Identifier of "LB1" and 
the message example was sent by the GWM in response to a request 
(MessageID: 0x32000000) for FARM1’s weights. 
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The TLVs necessary for this message are shown in the following list. 


alir SASP Header TLV 


| | Fiela | size | Value | 
BEE a Ed 
EE cea rrr io 
HEESE EL | 
EE a oa 
EES ra rs 


| | Fiela | Size | Value | 
DER SES 
EN ETT E 
pe a E ee | 
EE EE al 
ME EE eee 


*GWD Count = Group of Weight Data Count 


Figure 24 
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3. Group of Weight Data TLV 


| | Field | Size | Value | 
Er an la | 
o a] a 
a om 


*WE Count = Weight Entry Count 


Figure 25 
4. Group Data TLV 
| | Fiela | Size | Value | 
|----------- |--------- |------------ | 
|T| Type | 2 bytes | 0x3011 | 
L| Length | 2 bytes | 0x000E | 
ELE Ese | --------- | ------------ 
| |LBUID len| 1 byte | 0x03 
| |--------- |--------- |------------ | 
| | LBUID | 3 bytes | "LB1" or 
0x4C 42 31 
V EEEE ap 
| |GroupName| 1 byte | 0x05 | 
| | Length | | | 
| | Group | | "FARM1" or | 
Name 5 bytes 0x46 41 52 
4D 31 
Figure 26 
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5. Member Data TLV 


| | Fiela | Size | Value | 
a a lo] 
Re OE seke EG 
EE SE Ee | 
| REM E A | 
BE as a 
| | Address | | 0000 0000 
| | | | 0000 0000 

OAOA 0A01 
Gn cha | 
MEE a oe | 

Figure 27 
6. Weight Entry Data TLV 
EED Ca 
BEE ee Ee 
EE EE EE 
EE br | 
Wee ES | 
Wes EE A 
Figure 28 
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7. Member Data TLV 


| | Field | size | Value | 
a lo] 
Re OE seke EG 
EE SE Ee | 
MEE poa e ae 
BEG as a 
| | Address | | 0000 0000} 
| | | | 0000 o] 

OAOA 0A02 
Gn ch | 
ME a e | 

Figure 29 
8. Weight Entry Data TLV 
EED ee 
e E 
hee eee ED 
EE oe 
MEE EE | 
ME EE ee 
Figure 30 


A hex stream representing this same message is below: 
20 10 00 0D 01 00 00 00 6A 32 00 00 00 10 35 00 09 00 00 40 


00 01 40 11 00 06 00 02 30 11 00 OE 03 4C 42 31 05 46 41 52 
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AD 31 30 10 00 18 06 00 50 00 00 00 00 00 00 00 00 00 00 00 
00 OA OA OA 01 00 30 12 00 08 00 OD 00 28 30 10 00 18 06 00 
50 00 00 00 00 00 00 00 00 00 00 00 00 OA OA OA 02 00 30 12 
00 08 00 OD 00 14 
(106 bytes) 
9. Protocol Flow 


This section describes the expected general flow of the SASP 
messages. 


9.1. Normal Protocol Flow 


SASP first starts with a connection from an LB to the GWM. This is 
expected to be a long-running connection and will be used for many 
messages. After establishing the connection, the LB either registers 
a group of members or sets a Trust flag to allow the members to 
register themselves. The Trust flag is set using a Set LB State 
Request (both message flows are shown below). 


Registration from load balancer 


a Vers e ua ue ee er ee a egy beid SS q pa > 
Load Group Workload 

| Balancer | Registration Reply | Manager | 
| | anna | 
Set LB State from load balancer 

SEA SSeS StS = Set LB State Request —-—---~-------------— 
| | === >| | 
| Load | | Group Workload | 
| Balancer | Set LB State Reply | Manager | 
| [ensino nn | 

Figure 31 


Bivens Informational [Page 37] 


RFC 4678 SASPvl September 2006 


The connection can start with other requests, but any other request 
would likely result in an error (unless this connection is a 
reconnection that has happened a short period of time after the 
original connection). For example, if the load balancer issues a 
deregistration request as its first message, it will receive an error 
because it has not registered any groups. 


The load balancer always drops all state information after a loss of 
connection and can recover it using a GetWeights message. The 
establishment of a new connection causes the GWM to assume that the 
old one is broken. In this case, the GWM will keep all state for the 
load balancer for a limited time after a detected break. After the 
limited time has expired, all state for the broken connection will be 
discarded by the GWM. 


Registration of group members may be done at any time. A load 
balancer can register anywhere from one group with one member to many 
groups of many members. The member may also register itself if the 
Trust flag has been set and it knows the appropriate load balancer 
information. Registrations will add to groups that already exist, 
but return errors if any of the registered members already exist. 


In the case of system load balancing, the representation of a member 
is only the member's IP address with a 0 used as the value for the 
port and protocol. In the case of application load balancing, the 
representation of a member is the member's IP address and the 
Application's port and protocol. 


Deregistration of group members may be done at any time. A load 
balancer can deregister anywhere from one group with one member to 
many groups of many members. The LB may also deregister entire 
groups or deregister all of its groups at once. The member may also 
deregister itself if the Trust flag has been set and it knows the 
appropriate load balancer information. 


Once members are registered, the GWM will start the monitoring and 
weight computation processes to determine weights to be sent back to 
the load balancer. At any time the load balancer may issue a 
GetWeights message and ask for the weights for members in a 
particular group. The LB may also set a flag telling the GWM to send 
the weights without waiting for the GetWeights message. If this flag 
is set, the GWM will send the weights at an interval it feels is 
appropriate (the interval could change depending on the algorithm 
used and variance of the weights generated). 


At any time the LB or a particular member may quiesce the member 


through the use of a SetMemberState message. In this case, the 
member’s weight will always be zero, and the quiesce flag will be 
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turned on when sending its weight. Members may also use this message 
to send an opaque state value that will also be presented when 
sending weights. 


At any time, the load balancer may choose to send the GWM a 
SetLBState request to configure its interaction. The message allows 
the load balancer to set the Push, Trust, and NoChange_NoSend flags. 
It also allows the load balancer to pass a health value to the GWM to 
be displayed. 


Behavior in Error Cases 


While behaviors in many error conditions will be product specific, 
the following error cases should have the following expected 
behavior. 


Case: The protocol is violated in an unrecoverable manner by either 
end of the connection. 


Behavior: Either end of the connection may choose to disconnect to 
avoid future message synchronization problems. The state kept 
when disconnected is vendor specific. 


Case: LB or application attempts to connect to the GWM before the 
GWM is fully up and running. 
Behavior: The LB or application should wait at least 20 seconds to 


retry the connection. 


Case: Members attempt to register or deregister themselves before 
the LB develops the connection with the GWM. 


Behavior: In this case, the members would receive a reply with an 
error code signifying that there is no LB registered with that LB 
UID. 


Case: Member registers or deregisters for an LB who has not set the 
Trust flag. 


Behavior: GWM will send Member a reply containing an error code. 
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Case: LB asks for weights for a group that doesn't exist. 

Behavior: GWM will send LB a reply containing an error code. 

Case: LB or Member attempts to register a member that is already 
registered in that group. 

Behavior: GWM will send sender a reply containing an error code. 

Case: LB or Member attempts to deregister a member or group that 
doesn't exist. 


Behavior: GWM will send sender a reply containing an error code. 


Case: LB or Member tries to set state for a non-registered server. 


Behavior: GWM will send sender a reply containing an error code. 


Case: LB tries to Get Weights for an unregistered group. 


Behavior: GWM will send LB a reply containing an error code. 
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9.3. Example Flow 1: Load Balancer Registration, Getting Weights, and 
Application-Side Ouiescing 
Load Group Workload 
Balancer Manager 
| 1) Registration Reguest | 
0000000000 00000000 >| 
< A os E E Nm a q E a pl pç na E 
Registration Reply 
| 
| 2) Set LB State Request | 
|------------------------ >| 
|k------------------------ | 
| Set LB State Reply | 
| 3) Get Weights Request 
| o -- >| 
| <------~----------------- | 
| Get Weights Reply | 
| | 4) Set Member State Reg. -------- 
GAEERSSLERELERELELEEER SES Member 
-------------------------— >| A 
| | Set Member State Reply -------- 
| | 
| | 5) Set Member State Reg. -------- 
| |<------------------------- | Member | 
------------------------—-— sé 
Set Member State Reply  -------- 
| | 
| 6) Get Weights Request | 
| > >| 
Pd | 
| Get Weights Reply | 
| | 7) Set Member State Reg. -------- 
| E | Member | 
ma N EE >| c 
| | Set Member State Reply -------- 
| 8) Get Weights Request 
EE se aa >| 
RR OR | 
| Get Weights Reply | 
| 
Figure 32 
Bivens Informational [Page 41] 


78 SASPvl 


September 2006 


RFC 4678 SASPvl September 2006 
1. The LB registers Members A, B, and C in a group named GRP1. The 
GWM replies with no error. 
2. The LB turns its trust flag on by issuing a Set LB State message: 
LB Health: 0x00 Flags: 0000 0010 


3. The LB sends a Get Weights message for GRP1 and gets the reply: 


Members Opaque State Flags Weight 
Member A 0x00 0000 1101 20 
Member B 0x00 0000 1101 40 
Member C 0x00 0000 1101 5 


Member A 0x32 0000 0000 


5. Member C sends a Set Member State message to quiesce itself with 
the following flags: 


Members Opaque State Flags 


6. The LB sends the Get Weights message for GRP1 and receives the 


following: 
Members Opaque State Flags Weight 
Member A 0x32 0000 1101 20 
Member B 0x00 0000 1101 40 
Member C 0x0A 0000 1111 5 


7. Member C sends a Set Member State message to resume (un-quiesce 
itself) with the following flags: 


Members Opaque State Flags 


Member C 0x0A 0000 0000 
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8. The LB sends a Get Weights message for GRP1 and gets the reply: 


Members Opaque State Flags Weight 
Member A 0x32 0000 1101 20 
Member B 0x00 0000 1101 40 
Member C 0x0A 0000 1101 5 
9.4 Example Flow 2: Set Load Balancer State, Application 
Registration, and Load Balancer Group DeRegistration 
Load Group Workload 
Balancer Manager 
| 1) Set LB State Request | 
pet ee A EE pl q rj Se Ds > 
< Sd jo A e N fi pa o nd a e qe fd pi Si ie 
| Set LB State Reply | 
| | 2) Registration Request -------- 
| |<------------------------- | Member | 
----------------------—-- SA e] 
Registration Reply — -------- 
| | 3) Registration Request -------- 
| |<------------------------- | Member | 
| |------------------------- >| B | 
| | Registration Reply — -------- 
| 4) Send Weights Mesg | 
APA | 
| | 5) Registration Request -------- 
SE OE aS Saas Member 
Lo >| c 
| | Registration Reply — -------- 
| 6) Send Weights Mesg | 
| > | 
E Deregistration Request 
| -------=---------------- >| 
| <------------------------ | 
| Deregistration Reply | 
Figure 39 
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1. The LB sets its state with the Set LB State message and the 
following parameters. 


Health: 0x7F Flags: 0000 0011 


2. Member A registers itself for work in GRP1 using the Register 
message. 


3. Member B registers itself for work in GRP1 using the Register 
message. 


4. The GWM issues a Send Weights message to the LB. 


Members Opaque State Flags Weight 
Member A 0x00 0000 1001 20 
Member B 0x00 0000 1001 40 


5. Member C registers itself for work in GRP1 using the Register 
message. 


6. The GWM issues a Send Weights message to the LB. 


Members Opaque State Flags Weight 
Member A 0x00 0000 1001 20 
Member B 0x00 0000 1001 40 
Member C 0x00 0000 1001 5 


7. LB deregisters GRP1 by using the DeRegister message with the 
Member Data Count = 0 


9.5. Avoiding Single Points of Failure 


o To avoid having a single point of failure at the load balancer, an 
administrator may choose to have multiple load balancers in his or 
her environment. SASP provides for the GWM to keep track of 
multiple load balancers through the use of load balancer unique 
identifiers (LB UIDs). 


o To avoid having a single point of failure at the GWM or enhance 
the load balancing strategy by utilizing the strengths of several 
different GWMs, an administrator may choose to have multiple GWMs 
in his or her environment. In this case, the load balancer would 
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connect to multiple GWMs and register the same groups with 


corresponding members. The load balancer may choose to coordinate 
the recommendations of each GWM by any method it chooses (e.g., 
statistical combination such as averaging). The coordination of 


weights from multiple GWMs is product specific and not addressed 
in this protocol. 


Security Considerations 
SASP is a binary stream expected to be transported over a TCP 


connection. To secure this protocol, it is expected that 
implementers of the protocol use a secure mode of transport such as 


SSL/TLS. Discussions around security concerns have been listed 
below: 
Security Issue: In insecure environments, if the LB UID becomes 


known by another system, the other system could initiate a 
connection and send messages to the GWM causing the GWM to replace 
the previous (possibly valid) connection for the new (potentially 
bad) connection. 


Solution: This may not be a concern if the load balancer and GWM are 
in protected parts of the network. If the administrator is 
concerned about this vulnerability, she should use SSL or TLS to 
provide authentication for the connection. When using SSL or TLS 
to secure the connection, the administrator SHOULD use both server 
and client authentication through client and server certificates. 
The GWM will trust any certificate that is signed by an authority 
it's been configured to trust. 


Security Issue: In insecure environments, if the load balancer turns 
the Trust Flag on, any member or other system can send a 
Registration Message and be included in the serverfarm to receive 
work. A person with bad intentions and the correct information 
could exploit this feature and register his own application to 
receive work. His counterfeit application could capture valuable 
data from unsuspecting clients as their transactions are sent to 
his system. 


Solution: This may not be a concern if the GWM and its members are 
in protected parts of the network. If the administrator is 
concerned about this vulnerability, she should use SSL or TLS to 
provide authentication for the member connections. When using SSL 
or TLS to authenticate the connection, the administrator would 
need to explicitly install valid certificates on each component 
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while at the same time establishing the trusted certificates of 
each component. This would make certain that only those trusted 
components would be permitted to connect to the GWM. 
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